Hello programmers,
I've come across this again in the code and think I should ask you again now that the current system has been around for years.
I've been updating the collision detection of non-movable objects. There are so many objects around now, it has become quite inefficient to use the old system which uses the storage system of a movable physics object even for unmovable objects. I'm now using a much more compressed data structure for unmovable objects, that uses less memory and CPU.
But now that the movable and unmovable objects use a different type of data structure, it has become harder to support the reporting of contacts with unmovable objects.
I'm wondering if it is reasonable to stop reporting collisions with unmovable layout objects now. The way I'm thinking of this, the unmovable layout objects would be treated just the same as default non-layout objects that Eric has placed.
Movable objects would continue to be reported as before.
I've come across this again in the code and think I should ask you again now that the current system has been around for years.
I've been updating the collision detection of non-movable objects. There are so many objects around now, it has become quite inefficient to use the old system which uses the storage system of a movable physics object even for unmovable objects. I'm now using a much more compressed data structure for unmovable objects, that uses less memory and CPU.
But now that the movable and unmovable objects use a different type of data structure, it has become harder to support the reporting of contacts with unmovable objects.
I'm wondering if it is reasonable to stop reporting collisions with unmovable layout objects now. The way I'm thinking of this, the unmovable layout objects would be treated just the same as default non-layout objects that Eric has placed.
Movable objects would continue to be reported as before.
I don't have time to get into tyre physics at the moment but had some thoughts on it after Eeekie's post.
I think there are some competing effects when the throttle is applied.
1) As Eeekie described, the rear wheels become more loaded, lengthening the contact patch and so requiring less slip angle for a given lateral force. And conversely the front wheels become less loaded, get a shorter contact patch and require more slip angle for a given lateral force. From this point of view the car might take a wider line without any steering adjustment.
2) But there is another effect and that is that a wheel which has a longitudinal force applied, will produce less lateral force for a given slip angle. So from this point of view, a rear wheel drive car with more throttle applied (and no change in steering input) will follow a tighter line because the rear wheels will require a wider slip angle for a given force.
3) There are also other possible competing effects, such as the change in toe and camber due to suspension deflection, and the effect of a limited slip differential.
Now, I definitely may be wrong but I imagine number (2) above to be the dominant effect. I think that is how it is in my car but it would be hard to test unless I can find a skid pad. It may well be that a different effect is dominant in different cars, due to the different mass distributions and other design features. As I apply the throttle there is a whole range of slip angles before the point when the whole contact patch is skidding. Now I'm really not a crazy driver at all these days and don't drive much anyway but there are times when I can accelerate pretty hard out of a roundabout without any danger to myself or others. I can apply a lot of power without actually going sideways and it feels to me like it gets closer to oversteer through that process. It feels very planted and poised as I apply more power. A good part of my mind is focussed on the rear wheels, remembering I used to be a motorcyclist and am very aware of going over the limit. It's a feeling of confidence though and there is a certain joy to it. I believe I get this same feeling in the new physics of LFS, but in the old LFS there are some slight changes of line that don't seem to correspond with reality.
I think there are some competing effects when the throttle is applied.
1) As Eeekie described, the rear wheels become more loaded, lengthening the contact patch and so requiring less slip angle for a given lateral force. And conversely the front wheels become less loaded, get a shorter contact patch and require more slip angle for a given lateral force. From this point of view the car might take a wider line without any steering adjustment.
2) But there is another effect and that is that a wheel which has a longitudinal force applied, will produce less lateral force for a given slip angle. So from this point of view, a rear wheel drive car with more throttle applied (and no change in steering input) will follow a tighter line because the rear wheels will require a wider slip angle for a given force.
3) There are also other possible competing effects, such as the change in toe and camber due to suspension deflection, and the effect of a limited slip differential.
Now, I definitely may be wrong but I imagine number (2) above to be the dominant effect. I think that is how it is in my car but it would be hard to test unless I can find a skid pad. It may well be that a different effect is dominant in different cars, due to the different mass distributions and other design features. As I apply the throttle there is a whole range of slip angles before the point when the whole contact patch is skidding. Now I'm really not a crazy driver at all these days and don't drive much anyway but there are times when I can accelerate pretty hard out of a roundabout without any danger to myself or others. I can apply a lot of power without actually going sideways and it feels to me like it gets closer to oversteer through that process. It feels very planted and poised as I apply more power. A good part of my mind is focussed on the rear wheels, remembering I used to be a motorcyclist and am very aware of going over the limit. It's a feeling of confidence though and there is a certain joy to it. I believe I get this same feeling in the new physics of LFS, but in the old LFS there are some slight changes of line that don't seem to correspond with reality.
These are good questions but I'm not getting into tyre physics now.
I can't remember everything and will be starting with a good look into what we have and what is covered and what is not.
I can't remember everything and will be starting with a good look into what we have and what is covered and what is not.
It is hard to know but I will try to allow enough settings to run OK on lower spec computers. For example shadow maps can be made quite a lot faster by reducing the number of cascades and the distance that can be rendered, and switch off shadows in mirrors. Also you can switch off HDR mode, reduce texture resolution etc.
I can't really release them as they are because you can exploit the issues. So I hope to make them a better approximation of reality so that they are fun to drive on and respond in realistic ways to changes in settings. As far as I remember, total grip was actually less but they feel better and more intuitive, so actually more fun to drive. One example, sometimes in the RWD cars, in the old physics, you can put on a little more power and the car seems to follow a wider line, which shouldn't really be the case when you add more longitudinal force to the rear tyres. In reality and in the new system, more power in a RWD car always results in the car taking a bit tighter line. This is because the combination of forces is now done in a way that makes more sense and has a mathematical basis. The public version is more like a made up force combination, adjusted to try to match reality.
The free view video is only a demonstration. That mode is activated by a special button available in the development version so I can check how the occlusion is working. The free view doesn't use occlusion data normally, and doesn't need it so much as it's only the one view and no mirrors.
The fan can speed up quite a bit these days. The shadow maps, more complex shaders, higher resolution textures, more detailed models, HDR and bloom effect are definitely using more GPU power.
Yes this would be helpful for maintaining high frame rate as the CPU still has do do a lot of work asking the graphics card to draw things. So I will be thinking about this probably when I'm on the physics.
I did have to use 11 because InterlockedAdd was not allowed in feature level 10 and I couldn't think of another way to add to the histogram buffer.
Some possibilities here, the old 'read back a small texture and analyse on CPU' is still there for test purposes, so could be resurrected for Direct3D 10 GPUs. But I was thinking maybe feature level 10 could use the SDR mode and use time-based exposure instead. That would allow D3D10 graphics cards to use LFS but some things wouldn't be much good, e.g. it would be very dark in a car park.
But I don't know how many people have a Direct3D 10 graphics card as D3D10 was out a relatively short time before D3D11 was available. I think for now I'll keep trying to make sure it can run on them using SDR.
The new tyre physics is in this new version. So the situation is that it might be a bit hard to try to copy the old tyre physics from the public version, into this new version. I am more motivated to try and update the new tyre physics to an acceptable level. It is nice to drive with but needs some good work on load sensitivity, pressure and temperatures which are not correct.
Yes, I found in VR the exposure is calculated as dark if you use the whole view, because so much of the view is the car interior, so then it overexposed the image. So in LFS it limits the exposure check to a smaller square in each eye (both added together for a single exposure histogram). This limited square is 30 degrees each way, equivalent to a 60 degree FOV on a square monitor.
Thank you for the feedback, pleased you like the progress so far.
I have a bit more to do on the graphics, though I want to spend some time on the physics soon.
A couple of urgent things I can think of.
- I want to convert the 'individual car diffuse lighting calculated from dynamic environment map' into a compute shader so I can use it for all the cars that have an environment map. More distant cars will use the 'approximate diffuse' lighting that is currently in the paths. That's only about a day or two's work, I think, as it's a simple compute shader (and a conversion of existing code).
- The approximate lighting, for more distant cars and will also be useful for temporary objects like physics objects, layout objects and skid marks. It always was stored in the paths. But now I think it can use the occlusion octree, as that already covers all driveable areas. This sounds like a few days work.
- One obvious thing is clouds in the sky but I really don't want skies to prevent work on the physics. In my mind this can be released without clouds, but cannot be released without the physics updates.
- Various things on paper lists here but I am actually crossing them off faster than adding them now.
On Eric's side there are still plenty of holes and gaps at South City, mainly because there are really a lot of new roads and connections and he has been filling those new places up with detailed buildings. Some more holes to fill at Kyoto, and there is Fern Bay too. So both of us will still be busy for quite a while.
Thanks for the comparison shots!
Thank you for that!
I have a bit more to do on the graphics, though I want to spend some time on the physics soon.
A couple of urgent things I can think of.
- I want to convert the 'individual car diffuse lighting calculated from dynamic environment map' into a compute shader so I can use it for all the cars that have an environment map. More distant cars will use the 'approximate diffuse' lighting that is currently in the paths. That's only about a day or two's work, I think, as it's a simple compute shader (and a conversion of existing code).
- The approximate lighting, for more distant cars and will also be useful for temporary objects like physics objects, layout objects and skid marks. It always was stored in the paths. But now I think it can use the occlusion octree, as that already covers all driveable areas. This sounds like a few days work.
- One obvious thing is clouds in the sky but I really don't want skies to prevent work on the physics. In my mind this can be released without clouds, but cannot be released without the physics updates.
- Various things on paper lists here but I am actually crossing them off faster than adding them now.
On Eric's side there are still plenty of holes and gaps at South City, mainly because there are really a lot of new roads and connections and he has been filling those new places up with detailed buildings. Some more holes to fill at Kyoto, and there is Fern Bay too. So both of us will still be busy for quite a while.
Thanks for the comparison shots!
Thank you for that!
You reached a point which is outside the map square system. The rectangle of map squares is set to the size big enough to include all the default ground that is set to have physical properties. Outside that, there are no map squares for your objects to be registered on.
The map squares system is designed to rapidly identify nearby objects to check for physical contacts during each frame's physics calculations.
The map squares system is designed to rapidly identify nearby objects to check for physical contacts during each frame's physics calculations.
On the 'already existing mods causing bad collisions' reported issue:
The problem that mbutcher and Degats are talking about is that apparently some people are connecting with VOB mods and causing bad collisions, as if their collision box has been changed and the 'mysterious' part is they are not getting an OOS kick in this case.
It's not something that I can fix without being able to reproduce it. I've checked the code and if the code is working then the guest gets an OOS kick if any point or triangle of the physics mesh is different. Of course this is tested and known to be the case.
The easiest way around the OOS check but still use a VOB mod is as you say, to use a VOB mod that leaves the physics LOD unchanged. In that case the car's physics is not changed in any way and this should not be a problem online. I can't imagine anyone going to great lengths to somehow modify the exe to return correct OOS checks for modified physics boxes, as that would really be very difficult (I don't how they would even start with that) and pointless when there is a simple and safe alternative.
But just saying "more often than not, it turns out that the player involved has a VOB mod on the car they're driving" when there is a bad collision doesn't bring me any closer to the solution. I guess we need an example of a MOD that can bypass the OOS check, otherwise I am being asked to solve a problem that I cannot see, understand or reproduce.
The problem that mbutcher and Degats are talking about is that apparently some people are connecting with VOB mods and causing bad collisions, as if their collision box has been changed and the 'mysterious' part is they are not getting an OOS kick in this case.
It's not something that I can fix without being able to reproduce it. I've checked the code and if the code is working then the guest gets an OOS kick if any point or triangle of the physics mesh is different. Of course this is tested and known to be the case.
The easiest way around the OOS check but still use a VOB mod is as you say, to use a VOB mod that leaves the physics LOD unchanged. In that case the car's physics is not changed in any way and this should not be a problem online. I can't imagine anyone going to great lengths to somehow modify the exe to return correct OOS checks for modified physics boxes, as that would really be very difficult (I don't how they would even start with that) and pointless when there is a simple and safe alternative.
But just saying "more often than not, it turns out that the player involved has a VOB mod on the car they're driving" when there is a bad collision doesn't bring me any closer to the solution. I guess we need an example of a MOD that can bypass the OOS check, otherwise I am being asked to solve a problem that I cannot see, understand or reproduce.
It's just way too early for that. I'm actually not sitting here working on this mistaken 'quick idea' we decided to do yesterday. I'm working on something to do with lighting.
I'm not feeling there is a strong connection between these two issues.
1) You are talking about a problem that already exists where people are apparently using a mod and either a mysterious system or a bug that seems to bypass the collision sync check.
2) On the other hand we are talking about a new thing of allowing people to discuss modifications on our forum instead of being forced to do it out of sight from the rest of the community.
I'm not talking about changing (1) in any way by implementing (2). There is already code designed to prevent cheating and modification of the physics mesh. I've now been told that apparently there is some kind of bug with that, but I don't know how to reproduce the bug at this point. I need to keep a separation between considering a bug (1) and talking about allowing something that is hidden to become visible (2).
I just want to repeat: There's no rush. What I mean is no decisions will be made for at least a few days now.
Last edited by Scawen, .
Thanks, we are having a think about this.
This does not affect online usage.
The physics mesh (collision box) is included in the OOS check so the player is kicked if that is changed. That has been the case for as long as I can remember, otherwise such things would be used all the time. This change is only about allowing the discussing and sharing of mods.
Thank you for the VR test, Pistolero and Drifteris.
It's hard to make the AI faster because they are using the same physics and same grip, so it's difficult to give them the skill level of an experienced real driver.
But I have worked on them in the new tyre physics system and I think they are more challenging now. I need to work on the tyre physics after finishing some more graphical updates. I hope to release the new tyre physics with the graphical update.
It's hard to make the AI faster because they are using the same physics and same grip, so it's difficult to give them the skill level of an experienced real driver.
But I have worked on them in the new tyre physics system and I think they are more challenging now. I need to work on the tyre physics after finishing some more graphical updates. I hope to release the new tyre physics with the graphical update.
Not really senseless. Motorsports use timing at 1ms and that physics rate allows that accuracy in a simple way without interpolation.
1000 Hz physics at 60 Hz refresh rate would show visible frames with this step cycle:
16,17,17 <-- 50ms cycle, shown 20 times per second
I don't really know how bad it is to have graphical frames with that small variation in step time (some 16 ms, some 17 ms) but I'd guess it would not be very noticeable.
1000 Hz physics at 120 Hz:
8,8,9 <-- 25ms cycle, shown 40 times per second
1000 Hz physics at 90 Hz:
11,11,11,11,11,11,11,11,12 <-- 100 ms cycle, 10 times per second
I'm not sure if these 1ms variations every few frames would be noticeable.
Thanks for the test. LFS with D3D9 is quite heavy on the CPU as all the graphics and physics are loaded onto a single core, so there's no benefit from your 8 cores. I think the real solution is the new D3D11 version but unfortunately I can't give any estimate for when that will be released.
I'm taking this opportunity to update the OpenVR implementation for the D3D11 version. I might update to the latest OpenVR. I'll post here if I find anything or think of anything worth trying in the public version.
I'm taking this opportunity to update the OpenVR implementation for the D3D11 version. I might update to the latest OpenVR. I'll post here if I find anything or think of anything worth trying in the public version.
OK thanks, maybe 50 Hz would be a good option.
Let's consider how that would look on a 60 Hz monitor.
Each 1/10 of a second the video source has 5 frames (each of 2 physics steps). But our monitor will refresh 6 times.
So 50 Hz video on 60 Hz monitor (physics steps per monitor refresh) will be:
2, 2, 2, 2, 2, 0, 2, 2, 2, 2, 2, 0... (12 refreshes, 0.2 sec total)
Compared with my original 60 Hz video with this pattern:
2, 2, 1, 2, 2, 1, 2, 2, 1, 2, 2, 1... (12 refreshes, 0.2 sec total)
I can understand that the 50 Hz video will look smoother if you have a monitor that can use 50 Hz refresh rate. I guess the 60 Hz version will look smoother on a 60 Hz monitor.
Of course the best solution will be for LFS to be able to render intermediate frames between physics steps, or a completely different solution, use 1000 Hz physics and choose the nearest frame.
Let's consider how that would look on a 60 Hz monitor.
Each 1/10 of a second the video source has 5 frames (each of 2 physics steps). But our monitor will refresh 6 times.
So 50 Hz video on 60 Hz monitor (physics steps per monitor refresh) will be:
2, 2, 2, 2, 2, 0, 2, 2, 2, 2, 2, 0... (12 refreshes, 0.2 sec total)
Compared with my original 60 Hz video with this pattern:
2, 2, 1, 2, 2, 1, 2, 2, 1, 2, 2, 1... (12 refreshes, 0.2 sec total)
I can understand that the 50 Hz video will look smoother if you have a monitor that can use 50 Hz refresh rate. I guess the 60 Hz version will look smoother on a 60 Hz monitor.
Of course the best solution will be for LFS to be able to render intermediate frames between physics steps, or a completely different solution, use 1000 Hz physics and choose the nearest frame.
There is a problem with the public version of LFS in VR on some computers.
In fact there are two problems, and it seems to be worse on some computers than others.
1) LFS is rendered in D3D9 then a shared texture is used to update D3D11 render targets. Some code is used to try to time that well, and it seems to work quite well on some computers but I believe it is worse on others, judging by the descriptions.
2) LFS uses 100 Hz physics update and these steps do not correspond exactly with the refresh rate of any VR headsets.
In the best case, on many computers, only problem (2) is a real problem. In this case, the view looks quite good when looking straight ahead, but you can see a slight stutter when you look sideways. Different people might be more sensitive to that - you can see the stutter of the scenery, the 100 Hz physics updates being rendered at 90 Hz or 75 Hz or whatever.
In the worst case, on some other computers, apparently there is a worse stuttering problem. I think this is related to problem (1) which has now been eliminated in the current development version by using D3D11 for the main LFS render.
It's my understanding that nearly everyone has a 60 Hz monitor. I am obviously very well aware that LFS can currently only output video in steps of 0.01 seconds.
I'm surprised that you find it hard to understand my thinking. It's pretty simple. Maybe I am wrong (I'm not very experienced with youtube or video editing in general) but I am under the impression that youtube videos should ideally be 30 Hz or 60 Hz to run well on most monitors. So I thought the smoothest LFS videos I could possibly make would be 60 Hz ones, as I read that is the highest possible on youtube when I made the video (and now, I guess).
At 60 Hz, in 1/20 second there will be 5 LFS physics updates and 3 visible frame updates. So I output frames with steps of 2, 2, 1 each 1/20 of a second.
That cycle continues 2, 2, 1, 2, 2, 1, 2, 2, 1 and I believe that is the smoothest possible output for LFS on youtube at the moment. But if you know a better way, I'd like to hear it, rather than just hearing you say you can't understand why I would do that.
We are really far from a test version yet!
On my side there is still work to do on the graphics. I'm working on a bloom effect right now. I still need to improve the baked lighting rendering system to reduce some ugly vertex lighting issues you don't see too much of in my well-placed screenshots.
Then I still need to work on the physics and improve the security of the master server protocol.
Meanwhile Eric is continuing with South City, and still needs to finish Kyoto and update Fern Bay.
On my side there is still work to do on the graphics. I'm working on a bloom effect right now. I still need to improve the baked lighting rendering system to reduce some ugly vertex lighting issues you don't see too much of in my well-placed screenshots.
Then I still need to work on the physics and improve the security of the master server protocol.
Meanwhile Eric is continuing with South City, and still needs to finish Kyoto and update Fern Bay.
Thanks for the Valve Index feedback. I also have heard from a few other people that it was working fine. I guess you are using the test patch as I see you posted there.
I understand there is the frame rate mismatch. I'm interested to know if you think LFS looks better at 120Hz than at 90Hz.
My understanding is this:
90Hz: there is a 1/100th sec glitch forward every 1/10th of a second (a physics frame is missed 10 times per second).
120Hz: there is a tiny pause every 1/20th of a second (the same physics frame is drawn twice, 20 times per second).
I think these two cases would have a different appearance. Someone said that 120Hz looked better.
I understand there is the frame rate mismatch. I'm interested to know if you think LFS looks better at 120Hz than at 90Hz.
My understanding is this:
90Hz: there is a 1/100th sec glitch forward every 1/10th of a second (a physics frame is missed 10 times per second).
120Hz: there is a tiny pause every 1/20th of a second (the same physics frame is drawn twice, 20 times per second).
I think these two cases would have a different appearance. Someone said that 120Hz looked better.
Thanks everyone for the feedback.
Yes, from the point of view of force feedback, no higher frame rate than 100 should make a difference.
Less than 100 fps will reduce the number of FF updates you get (because there is never more than one FF change per visual frame, which will be the case as long as LFS runs graphics and physics on the same thread) so going lower than 100 fps makes a difference that may be perceptible on the very high end wheels.
I didn't want to bother explaining how the old system worked, now that it has been deleted. But as people like to understand, here goes:
In the old system, there was some code that reduced the number of FF updates sent from LFS to the wheel drivers (to avoid overload which was a problem in the past, and may still be now, for some wheels) by making sure some number of frames had elapsed since the previous FF update. That number of frames depended on how different the current force was to the last force sent (more different, less frames needed to elapse). The relevant point is that it was related to a number of frames, so people discovered that having otherwise pointless frame rates like 1000 fps gave them more immediate force feedback. Now that code is gone, and you can set to allow 100 Hz FF updates, there is no need to use extremely high frame rates as you can't get higher then 100 Hz FF updates anyway.
Yes, from the point of view of force feedback, no higher frame rate than 100 should make a difference.
Less than 100 fps will reduce the number of FF updates you get (because there is never more than one FF change per visual frame, which will be the case as long as LFS runs graphics and physics on the same thread) so going lower than 100 fps makes a difference that may be perceptible on the very high end wheels.
I didn't want to bother explaining how the old system worked, now that it has been deleted. But as people like to understand, here goes:
In the old system, there was some code that reduced the number of FF updates sent from LFS to the wheel drivers (to avoid overload which was a problem in the past, and may still be now, for some wheels) by making sure some number of frames had elapsed since the previous FF update. That number of frames depended on how different the current force was to the last force sent (more different, less frames needed to elapse). The relevant point is that it was related to a number of frames, so people discovered that having otherwise pointless frame rates like 1000 fps gave them more immediate force feedback. Now that code is gone, and you can set to allow 100 Hz FF updates, there is no need to use extremely high frame rates as you can't get higher then 100 Hz FF updates anyway.
Last edited by Scawen, .
Direct Drive Wheels - New FF patch and information request [OLD THREAD]
EDIT: This was for a test patch in the 0.6 era
For racers who have a Direct Drive wheel, Test Patch U7 has some new settings that allow you to remove a notchy force feeling and receive force updates with the minimum delay. And there is no longer a reason to use frame rates above 100 fps.
For OSW wheels the recommended settings are:
FF Steps -> 10000 (for max resolution allowed by DirectInput)
FF Rate -> 100 Hz (allows FF updates to match LFS physics rate)
I am interested to know if these are the best settings for all direct drive wheels. And to allow for the possibility of automatic presets, it would be useful to know the exact name of your wheel as it appears in LFS (see attached screen shot).
EDIT - test patch download link removed - all these updates are in the latest official version
The update does allow better settings for ordinary geared wheels too, but it is not recommended to go for the maximum. The default settings (Steps 400 Steps / Rate 50 Hz) may be all you need.
For racers who have a Direct Drive wheel, Test Patch U7 has some new settings that allow you to remove a notchy force feeling and receive force updates with the minimum delay. And there is no longer a reason to use frame rates above 100 fps.
For OSW wheels the recommended settings are:
FF Steps -> 10000 (for max resolution allowed by DirectInput)
FF Rate -> 100 Hz (allows FF updates to match LFS physics rate)
I am interested to know if these are the best settings for all direct drive wheels. And to allow for the possibility of automatic presets, it would be useful to know the exact name of your wheel as it appears in LFS (see attached screen shot).
EDIT - test patch download link removed - all these updates are in the latest official version
The update does allow better settings for ordinary geared wheels too, but it is not recommended to go for the maximum. The default settings (Steps 400 Steps / Rate 50 Hz) may be all you need.
Last edited by Scawen, .
As the Fanatec is direct drive, have you tried the new settings in the test patch?
For OSW wheels the recommended settings are:
FF Steps -> 10000 for max resolution allowed by DirectInput
FF Rate -> 100 Hz allows FF updates to match LFS physics rate
For OSW wheels the recommended settings are:
FF Steps -> 10000 for max resolution allowed by DirectInput
FF Rate -> 100 Hz allows FF updates to match LFS physics rate
The idea of the new settings is for high end, direct drive FF wheels you may wish to go for the maximum value of FF Steps and FF Rate. This will give you the maximum number of updates from LFS physics, at the maximum resolution allowed by DirectInput.
On lower end wheels (standard wheels with gears or belts) there will not be so much benefit in going for these high update rates and there may be a CPU cost and possibly lag if you go for the full unlimited rate. So I suggest you don't go higher than you need if the difference is not noticeable on your wheel.
About the connection between visual frame rates and force feedback:
In the old system there was a reason to go for higher frame rates to get more immediate force feedback. But this is now controlled by these user settings and there should be no reason to go higher than 100 fps (LFS physics update rate).
On lower end wheels (standard wheels with gears or belts) there will not be so much benefit in going for these high update rates and there may be a CPU cost and possibly lag if you go for the full unlimited rate. So I suggest you don't go higher than you need if the difference is not noticeable on your wheel.
About the connection between visual frame rates and force feedback:
In the old system there was a reason to go for higher frame rates to get more immediate force feedback. But this is now controlled by these user settings and there should be no reason to go higher than 100 fps (LFS physics update rate).
I think you could set it to 100 and then you'll get a 90 Hz output. It would always output the steering torque from the last physics update.
I'm planning to add these settings to the Axes / FF tab in Options - Controls so we can see the effect more quickly.
I'm planning to add these settings to the Axes / FF tab in Options - Controls so we can see the effect more quickly.
I can see why going to a very high frame rate can help get more force updates. The output is limited in a way that does depend on the frame rate. It's really old code and I'm not happy with how that works. Ideally there should be no advantage in going above 100 fps.
I think I need to make a change that allows the force output to be limited in a controllable way that does not depend on the frame rate (if the frame rate is 100 Hz or higher).
I'm thinking we need two settings.
1) FF Steps : from about 500 to 10000
2) FF Max Update Rate : from about 25 to 100 Hz
For a high end wheel like yours you would set both to the maximum and that would allow the best connection between LFS and DirectInput, if your frame rate was 100 Hz. In that case there could be an output after every physics update, if the force changed according to the available DirectInput resolution (0 to 10000).
For a lot of wheels the force outputs must be limited and I'm guessing that 500 steps and 25 Hz output may be enough, but I'll know more after I implement this.
I think I need to make a change that allows the force output to be limited in a controllable way that does not depend on the frame rate (if the frame rate is 100 Hz or higher).
I'm thinking we need two settings.
1) FF Steps : from about 500 to 10000
2) FF Max Update Rate : from about 25 to 100 Hz
For a high end wheel like yours you would set both to the maximum and that would allow the best connection between LFS and DirectInput, if your frame rate was 100 Hz. In that case there could be an output after every physics update, if the force changed according to the available DirectInput resolution (0 to 10000).
For a lot of wheels the force outputs must be limited and I'm guessing that 500 steps and 25 Hz output may be enough, but I'll know more after I implement this.
Hmm, I wonder what I really said. That doesn't sound right, because LFS is supposed to be a form of entertainment. That *should* be a small part of "making your life better" just as watching a good film or reading a book can do.
Definitely we all should relax, have fun and play around a bit and that is a good thing and this is my intention for LFS.
There is also an educational aspect to it, in the sense that a lot of people have learned more about driving, physics, racing and so on. As it becomes more realistic, the educational aspect improves. On my side with the physics and on Eric's side the structure of race tracks, roads and so on. This is also supposed to be a small part of "making your life better" if you want to put it that way.
Of course, if it becomes an irritation or a frustration, you should move on. We have an email notification system so we can let you know when there is an update.
In no way is LFS supposed to be a thing which people sit around for years waiting for updates and becoming increasingly angry. Anyone who does that is bringing it upon themselves.
FGED GREDG RDFGDR GSFDG